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IMPLEMENT A TION OF A 
PROTOTYPE PROGRAMMING ENVIRONMENT 

PART VI 



Bruce J. MacLennan* 
Computer Science Department 
Naval Postgraduate School 
Monterey, CA 93943 



Abstract: 

This is the last report of a series exploring the use of the Q programming notation to prototype a program- 
ming environment. This environment includes an interpreter, unparser, syntax directed editor, command 
interpreter, debugger and code generator, and supports programming in a small applicative language. This 
report presents a universal (i.e., table-driven) syntax directed editor and unparser, which requires only 53 
rules to express. A running implementation of these ideas is listed in the appendices. 



L Goals 
A. Introduction 

Our goal in this series of reportsf [MacLennan85b, MacLennan85c, MacLennan86a, MacLennan86b, 
MacLennan86c] is to explore in the context of a very simple language the use of the O programming nota- 
tion [MacLennan83, MacLennan85a] to implement some of the tools that constitute a programming 
environment. 

In Part VI we address the following problem: Each extension to the language has required new rules to 
be added to the unparser and editor. However, the new rules have been very similar in every case. There- 
fore, our goal will be to make the unparser and editor table- driven (like a table-driven parser) so that only 
the tables need be changed when the language is extended. 

What information needs to be provided to permit table-driven syntax-directed editing? We will cer- 
tainly need the sort of syntactic information normally provided in a BNF grammar. This tells how pro- 

* Author’s current address: Department of Computer Science, Ayres Hall, University of Tennessee at Knoxville, Knoxville, 
Tennessee, 37996-1301. 

t Support for this research was provided by the Office of Naval Research under contract N00014-86-WR-24092. Preparation of 
this report was supported by ONR under contract N00014-87-WR-24037. 



- 1 - 



gram trees are unparsed onto the display. An example of the sort of information required is shown in 
Table 1, which contains the grammar for our sample language; we will take it as typical of the kinds of 
grammars we would like to handle. 



TABLE 1. Grammar for Sample Language 



<program> 


= <expr> 






<expr> 


= < 2 w*ex> <rel> 
1 <arex> 


<arex> 


<rel> 


II 

A 

V 

/A 

W 


= 1 


7^ 


<arex> 


= <arex> { + | 
1 <term> 


-} 


<term> 


<term> 


= <term> { x | 
1 <factor> 




<factor> 


<factor> 


= <number> 







I <var> 

I <var> <factor> 

I ( <expr> ) 

I (if <expr> 
then <expr> 
else <expr> ) 

I [let <var> = <expr> 

<expr> ] 

I [func <var> <var> = <expr> 

<expr> ] 

B. Editing Commands 

If we are to automatically generate a syntax-directed editor then we also need to know the selector-keys 
associated with the various language constructs. Table 2 shows an example of this information for the case 
of the sample language. 

These selector commands are language- dependent^ i.e., they depend on the kinds of constructs included 
in the language (although we would hope for some consistency in their choice). A number of other com- 
mands are language-independent: they are the same for all languages. For example, we have the naviga- 
tion commands: 
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TABLE 2. Selector Keys for Sample Language 



= 


—*■ 


<arex> = <arex> 


n 




<arex> ^ <arex> 


< 




<arex> < <arex> 


> 


- 


< 2 irex> > <arex> 


1 


- 


< 2 trex> ^ <arex> 


] 




<arex> ^ < 2 irex> 


-f 




< 2 irex> -h <term> 


— 


- 


<arex> — <term> 


♦ 


- 


<term> x <factor> 


/ 


- 


<term> -r <factor> 


# 


- 


<number> 




- 


<var> 


c 


- 


<V 2 LT> <factor> 


( 




( <expr> ) 


i 




(if <expr> then <expr> else <expr> ) 


1 




[let <var> = <expr> <expr> ] 


f 




[func <var> <v 2 lt> = <expr> <expr> ] 



in, out, next, prev, root 



We also have the delete command, which works on any language construct (the insertion commands are 
language-dependent; they 2 ire the selector keys). Finally, we will postulate a single mechanism for entering 
strings of chziracters, whether for identifiers, literal constants, comments, or whatever: 



_C,C2Cs • • • 

The key (typically the spacebar) initiates the accumulation of characters, and the key (typically the 
C2irriage return) completes the accumulation and enters the string into the structure. 

C. Example Session 



Suppose we wish to enter the following program: 



[let K = 16 
[fane fac n = 



(if n = 0 



then 1 

else n x fac (n -- 1) ) 
fac (K -r 2) ] ] 



When the system is entered we will be prompted for a program: 
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<program> 



Typing the ‘P selector key calls for the creation of a let block^: 

1 

[let < var> = <expr> 

<expr> ] 

The bound variable is entered, and we move to the bound value: 

_K@ next 
[let K — <expr> 

<expr> ] 

The literal constant ‘16’ is entered, and we move to the body: 

next 
[let K = 16 
< expr> ] 

The T key calls for the creation of a function definition block: 
f 

[let K = 16 

[func <var> <var> = <expr> 

<expr> ] ] 

The function name is entered: 

_fac@ next 

[func fac < var> = <expr> 

<expr> ] 

The formal parameter is entered: 
next 

[func fac n = < txpr> 

1. In each case we show the command typed, followed by the resulting display. 
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<expr> ] 



An if expression is requested: 
i 

[func fac n = 

(if <expr> 
then <expr> 
else <expr> ) 

<expr> ] 

For the expression ‘n = O’, we first enter the operator: 



< arex> = <arex> 

Next we enter the variable ‘n’ and move right: 

_n@ next 
n = <arex> 

The condition is completed by entering the number ‘O’: 

#_ 0 @ 

n = 0 

Moving right focuses attention on the consequent of the conditional: 

next 
(if n = 0 
then <€xpr> 
else <expr> ) 

The literal constant ‘1’ is entered as the consequent of the if: 

1 

The next component is the alternate: 
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next 



(if n = 0 
then 1 

else <expr> ) 

The product of n and the factorial of n— 1 is entered as the alternate. First we request a product: 

* 

<term> x <factor> 

We enter the variable ‘n’ and move right: 

n@ next 
n X <factor> 

The ‘c’ key requests a function call: 
c 

n X < var> <factor> 

We enter Tac^ and move right: 

fac@ next 
n X fac <factor> 

For the argument we request a parenthesized expression: 

( 

n X fac ( <expr>) 

Notice that the closing parenthesis is automatically supplied, so there is no possibility of misnested 
parentheses. The ‘ — ’ key requests a difference: 



n X fac { <arex> — <term>) 

The difference is completed routinely: 
nQ next # 1@ 
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n X fac (n — 



Moving to the next component brings us to the body of the function definition block: 
next 

[let K = 16 
[func fac n = 

(if... 
then ... 
else ... ) 

<ezpr> ] ) 

We have shown the components of the conditional as representing suppressed detail, although on a 
reasonably sized screen the entire program would be shown. (This suppression of detail is called holo 
phrasting in the literature.) The body of the function definition block is the invocation of factorial with 
k^2: 

c _fac@ next / _K@ next 
fac (K ^ 2) 

We shift our focus back to the root, where we see the completed program: 
root 

[let K = 16 
[fane fac n = 

(if n = 0 
then 1 

else n x fac (n — 1) ) 
fac (K - 2) ] ] 

D. Transaction Grammar 

How might we express concisely the connection between concrete syntax, abstract syntax and editing 
commands? We will use a translation grammar augmented by selector keys, which we call a transaction 
grammar. There are a variety of notations for transaction grammars. For example: 
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<arex>: 



+ -► <arex> -h <term> 

=$> Sum (Left = <arex>, Right = <term>) 

► <arex> — <term> 

=> Dif (Left = <axex>, Right = <term>) 

else <term> 

This means that if a key is typed, then a Sum node is generated (which is unparsed ‘<arex> H- 
<term>’). The else clause means that if any key other that ‘-h’ or ’ is typed when <arex> is expected, 
then that key will be “forwarded” to the <term> rule. For example, if a ‘/’ is typed when an <arex> is 
expected, it will be passed to <term>, where it will generate a Quo (quotient) node. 

Note we have made some changes to abstract syntax: instead of one Appl node we now have different 
nodes for the different operations (Sum, Dif, etc.). This simplifies unpaxsing. 

We will use a slightly different notation for transaction grammars that is more compact, since it merges 
the analysis and synthesis parts of the rule. For example, the rule for <arex> is: 

<arex> 

+ (Sum) -> Left:<arex> + Right:<term> 

— (Dif) -> Left:<arex> — Right:<term> 
else <factor> 

This say that a ‘-h’ key creates a Sum node, whose Left component is an <arex> and whose Right com- 
ponent is a <term>. Table 3 shows most of the transaction grammar for the sample language; only rou- 
tine parts have been omitted. 

n. Requirements 

What sort of tables are needed? We will consider the data structures needed to support language- 
independent (A) unparsing and (B) syntax- directed editing. This will allow us to define the necessary rela- 
tions. 
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TABLE 3. Transaction Grammar for Sample Language 



■ <program> = 


<expr> 


<expr>:> 


— (Eql) -► Left:<arex> = Right:<arex> 
n (Neq) Left:<arex> = Right:<arex> 




else <arex> 


<arex>: 


-h (Sum) Left;< 2 u*ex> + Right:<term> 
— (Dif) Left:<arex> — Right:<term> 
else <term> 


<term>: 


* (Prd) Left:<term> x Right: <factor> 
/ (Quo) Left:<term> Right:<factor> 
else <factor> 


<factor>: 


§ (Con) -► LitVal:< chars > 
c (Call) Rator:<chaj-s> Rand:<factor> 
( (Par) -► ( Exp:<expr> ) 




i (ConEx) -► %I%N (if Cond:<expr> 
%N then Conseq:<expr> 

%N else Alt:<expr> ) %0 




1 (Block) %I [let BndVar:<chars> = BndVal:<expr> 
%N Body:<expr> ] %0 




f (FunDef) -► %l [func FunName:<chars> FunFormal:<chars> = FunBody:<expr> 
%N FunScope:<expr> ) %0 




else (Var) -> Ident:<chars> 



A. Unparsing 



i. Alternates 



For each syntactic category, e.g., <expr>, we must be able to select an image-template based on the kind 
of node (the node variant). E.g. 



Block => [let — = ] 

ConEx (if — then — else — ) 



These are called alternates of the syntactic category. 



2. Image- templates 



For each alternate, we need an image- template, which is a sequence of items. Items are either terminals or 
nonterminals , 



a) Terminals are strings of characters and formatting commands (e.g., tabs and newlines). E.g., 






b) Nonterminals must specify: 

i. An associated selector relation, e.g., Cond, Conseq or Alt for ConEx nodes. 

ii. A syntactic category determining what can legally occur in that position, e.g., <expr> for the Cond 
part of a ConEx. This is needed for: 

• Prompting for the required category 

• Determining the format by which to display a component 

c) There are two kinds of image templates: 

i. Simplex 

ii. Complex 

i. A simplex template is composed of a single nonterminal, possibly surrounded by terminal items, e.g. 

<expr> 

It does not break a node into its components for unparsing, but relies on the nonterminal’s rule to do this. 

ii. A complex template breaks a node into its components and unparses each component according to a 
given nonterminal. These unparsed results are catenated with appropriate terminals between and around 
them, e.g. 

(if” Cond:<expr> 
then” Conseq:<expr> 
else Alt:<expr> “) %0” 
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S, Display Control 



We will also need a means for displaying the context of the current node, i.e., the surrounding tree struc- 
ture. We want to display the context of the current node, but without zooming in or out too frequently 
(which would confuse the user). Furthermore, we want to suppress sufficient detail so that the displayed 
region of the tree will fit on the display screen. Therefore we define parameters for controlling the display 
as depicted in Figure 1. 




‘Display’ represents the region of the tree presented on the screen. Detail below the ‘Depth’ level is 
suppressed so that the displayed region will fir on the screen. ‘Focus’ refers to the current node, to which 
commands refer. It is unparsed in a distinctive way (typically, in inverse video). The focus can be shifted 
anywhere within the displayed area. However, if the focus reaches the depth limit, then the display zooms 
in (i.e., the Display node shifts down). If the focus reaches the display root, then the display zooms out. 
This policy minimizes movement pi Display. 

B. Syntax-Directed Editing 

' We must consider: 

1. Creation of program trees 

2. Deletion of subtrees 

3. Motion within the program tree 
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i. Creation 



a. We need to be able to select a node kind out of those that 20*e legal at a given position. E.g., if an 
<expr> is expected, then we must be able to select Var, Appl, ConEx, etc. Further, we must specify the 
command key associated with each selection. 

b. We need to know the selector relations, so that undefined components can be created when a node is 
created. E.g., when a ConEx node is created, we need to link it to new undefined nodes by the Cond, Con- 
seq and Alt relations. 

c. We need to know which component (i.e., selector relation) is first (i.e., leftmost in display order) so that 
the focus can be shifted there. E.g., when a ConEx node is created, the focus should be shifted to its Cond 
component. 

d. We need to know the next component (i.e., selector relation) in display order so that focus can be 
shifted to the right as each component is completed. E.g., when the Cond of a ConEx is finished, we shift 
to the Conseq, and when that is done to the Alt. 

e. We need to be able to “chain’’ from grammar rule to grammar rule. E.g., Suppose ‘-h’ and ’ are legal 
command keys for <arex>, and ‘x’ and are legal keys for <term>, and ‘(* and are legal for <fac- 
tor>. Also suppose a <factor> is a legal <term> and a <term> is a legal <arex>. Then, typing a ‘x’ 
where an <arex> is required should chain to the <term> rule, and typing where an <arex> is required 
should chain to the <factor> rule. 

2, Deletion 

a. We need to know the syntactic category expected after a deletion. For example, when a Quo node is 
deleted from the Conseq component of a ConEx, the user should be prompted for <expr>. 

b. We need to know all selector relations for a node kind, so that all its components can be deleted. 

3. Motion 

a.. We need to know next and previous nodes in display order. N.B., there is no next or previous inherent 
in the abstract structure; the display order is determined by the concrete syntax. 
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b. We need to know first node in display order, for the in command. 



c. We need to be able to get to the parent node, for the out command. Note that there is no one selec- 
tor relation that links a node to its parent. 

m» Outline of Relations 

Based on the preceding analysis we outline the relations required to support the necessary data structures. 
The requirements supported by a relation are listed in brackets following the description of the relation. 

A. User Interface 

The relations used for interfacing to the user are similar to those used in Parts I through V. 

• Command (-4, c) 

Agent A issues command c. 

Note that ‘Command’ has been changed from a one-place to a two-place relation; this simplifies com- 
mand synchronization since it allows ‘Command’ to be called as a procedure, ‘Command {c}’. 

• Argument («) 

s is the argument string. 

• Error (A, «) 

Agent A reports error message s. 

As usual we assume the existence of the ‘display’ procedure. 

B. Kinds of Templates 

Whenever we refer to a template T we mean the first item in the chain of items constituting the template. 

• Template ( T, K, N) 

T is the image template for node variant V under nonterminal N. [Al] 

• DefaultTemplate (T, N) 

T is the default template for nonterminal N. [Al, Ble] 

• Complex (T) 

r is a complex template. [A2c] 
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Thus, the data structures for a nonterminal such as <arex> look like this: 




Figure 2. Data Structures Representing the Nonterminal <arex> 

Nonterminallmage is described in D, below. 

C. Parts of Templates 

These relations and those in the next section represent the parts of templates. In this section we describe 
the relations that represent the sequencing of items and the representation of terminal items. 

• Nextitem (J, /, N) 

J is the next item after 1 in an image template for nonterminal N. [A2j 

• Terminal (/) 

/ is a terminal item |A2a, A2b] 

• Terminallmage (5, /) 

5 is the image of terminal item I. [A2a] 

D. Nonterminals 

These relations represent nonterminals, including the node components to which they correspond, their 
syntactic category, and the string that represents them to the user. 
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• Selector {R, /, T) 

R is tlie selector for nonterminal item 7 in template T, [A2bi, B2a] 

• Category (M, 7, T) 

M is the syntactic category of nonterminal item 7 in template T. [A2bii] 

• Nonterminallmage (5, TV) 

5 is the image of nonterminal TV. [A2bii] 

The following figure displays the data structures corresponding to the template: 

Left :<arex> ‘ 4- ’ Right: <term> 



Complex Terminal 




Figure 3, Data Structures for the Template: Left:<arex> ‘ H- ’ Right:<arex> 

Note that for clarity we have omitted from the diagram the third fields of Next Item, Selector and 
Category. 

E. Display Control 

These relations control the region of the program displayed on the screen and control the suppression of 
low-level detail. 

• DisplayRoot (E) 

E is the display root. [A3] 

This relation determines the region of the tree displayed on the screen. It is the node at which unpars- 
ing begins. 
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• CurrentNode 

E is the current node. [A3] 

This relation determines the node that is the object of all editor commands (i.e., the focus of editing). 

• DepthLimit (d) 

d is the depth limit. [A3] 

This parameter determines the depth beyond which detail is suppressed. 

• CurrentDepth (/) 

/ is the depth of current node. [A3] 

This is used to determine when the depth limit is exceeded. 

• AssumedTemplate ( T, V") 

T is assumed template for node type V. [A3, B2a] 

This is used to determine the template by which to unparse the display root. 

These parameters are described in more detail later. 

F. Variant Selection 

The following relations are used for identifying language-dependent creation keys, forwarding them from 
rule to rule, and associating them with node variants. 

• ExecutiveCommand (A:) 

Key k is an executive command. [Bla] 

This is used for discriminating between the language-independent “executive command keys” and the 
language-dependent selector keys. 

• VariantKey (k, V, N) 

Key k selects variant V of nonterminal N. [Bla] 

For example, selects variant ‘Sum’ of <arex>, and ‘ — ’ selects variant ‘DiT of <arex>. 

. DefaultNT (V, M) 

Nonterminal N is the default alternative nonterminal M. [Ble] 

For example, <term> is the default nonterminal for <arex>. 
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G. Node Format 



These relations specify the left-to-right (in display order) relationship among the selectors of a node. For 
example, in the template 

‘%I%N (if’ Cond:<expr> 

‘%N then ’ Conseq:<expr> 

‘%N else ’ Alt:<expr> ‘ )%0’ 

the defined order of selectors is (Cond, Conseq, Alt). Note that we might easily have a different template 
that displays the components in a different order: 

Conseq:<expr> \ if’ Cond:<expr> 

‘%N’ Alt:<expr> otherwise ‘%0%N’ 

This template defines the order (Conseq, Cond, Alt). The relations describing selector order are: 

• FirstSelector (i2, T) 

R is first selector for template T. [Bib, Blc, B2b, B3b] 

For example, “Cond” is the first selector for the template for conditional expressions. 

• NextSelector (5, i?, T) 

S is next selector after R in template T. [Bib, B2b, B3a, Blc] 

For example, “Conseq” is the selector after “Cond” in the conditional expression template. 

• LastSelector (i2, T) 

R is the last selector for template T. [Bib, B2b, B3a, Blc] 

For example, “Alt” is the last selector in the conditional expression template. 

H. Node Structure 

The following relations define the actual format of nodes. This is a difference from previous reports in this 
series. Rather, than using individual predicates to tag each node type. Con {E), Block (E), etc., we now 
use a single Type relation to attach the type. Hence we have Type (“Con”, E), Type (“Block”, E), etc. 
(the tag is simply a character string). Similarly, instead of representing node components by a number of 
specialized relations, LitVal (V, £*), BndVar (N, E)^ etc., we now use a single Component relation, so we 
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have Component ( K, “LitVal”, E)^ Component (iV, “BndVar”, E), etc. Hence component relations are 
simply strings. 

• Type(V,E) 

V is the type of node E. [Al, Bl, B3b) 

• Component (A, Y) 

X is the R component of Y. [B2a, B3c) 

This completes the description of the principal relations used in the table-driven syntax-directed editor, 
viz., those relations that define the tables. There will of course be a number of active relations used to con- 
trol the activities of the editor; these will be introduced as they are needed. 

rV. Rules for the Table-Driven Syntax-Directed Editor 

In this section we present most of the 53 rules required to implement the editor (the complete system is 
listed in Appendix A). Many of the rules are largely self explanatory, so they are presented with minimal 
commentary. 

A. Focus Movement 

These commands shift the focus under control of the template and node description. They all make use of 
the procedure ‘SetCurrentNode’, which shifts the focus and in addition determines if this focus movement 
requires the display root to be moved. 

i. in Command 

For an in command, we follow the branch for the first selector for the template associated with the focus’s 
node type: 

^Command (return, in), CurrentNode (£"), Type ( F, £'), AssumedTemplate ( T, F), 

FirstSelector (R, T), Component (A, R, E) 

=> (Set CurrentNode {A}; Command (return, display)}. 

The in command, like all navigation commands, issues the display command, which refreshes the screen. 
We use to indicate sequential action, since we want the focus to be shifted before the display is 
refreshed. 
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Also note that by passing ‘return’ to the Command procedure in the effect part of the rule we have 
made Command tail-recursive. The effect part could have been written recursively, but it would be less 
efficient: 

• * * => {SetCurrentNode {X}; Command {display}; return (Nil)}. 

Error conditions can be handled by an else rule: 

else *Command (return, in) 

Error (return, “No inner component.”). 

We assume ‘Error’ is a procedure that takes appropriate error reporting action. In general we omit show- 
ing the error handling rules, since they are routine. 

2. out Command 

The out command is very simple; we move to the parent of the current focus: 

*Command (return, out), CurrentNode (X), Component (X, "—,"£') 

=> {SetCurrentNode {£*}; Command (return, display)}. 

In effect the rules says, “If the current node is some component of another node, then move to that other 
node.” 

3. next Command (next on same level) 

For then next command we determine the selector corresponding to the current node and, via the assumed 
template for the parent node type, find the selector that follows the current one in that template. This 
allows selecting the new current node. 

*Command (return, next), CurrentNode (X), Component (X, £*), Type ( V', E), 

AssumedTemplate (T, V), NextSelector (5, R, T), Component (Y, 5, E) 

=> {SetCurrentNode { F}; Command (return, display)}. 

4- next Command (next on level above) 

If there is not a next selector at the current level in the tree, then we shift the focus to the parent of the 
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current node and reissue the next command: 



*Command (return, next), CurrentNode (X), Component {X, R, E)y Type {V, E), 

AssumedTemplate ( T, V), — -NextSelector (— , R, T) 

=> {SetCurrentNode {E}] Command (return, next)}. 

Thus, when we hit the next key, we will continue zooming out until either we reach a level where there is 
a next component, or we reach the root. The prev command is exactly analogous. 

B. Focus Motion 

1. Simple Version 

In the simplest definition of the SetCurrentNode procedure simply moves the focus: 

*SetCurrentNode (return, X), *CurrentNode (£) 

==> CurrentNode (X), return (Nil). 

The reason we have defined SetCurrentNode is to permit a more complicated version that shifts the 
DisplayRoot if necessary. 

2. Display Parameters 

To understand the operation of SetCurrentNode it is necessary to understand the role of the various 
display parameters (see Figure 4). 
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The parameters are as described before (Figure 1) except that CurrentDepth records the current depth at 
which unp 2 ursing is taking place. When this exceeds DepthLimit, further unparsing is suppressed. 

3, Upward Motion: Shift Needed 

When an attempt is made to shift the focus to the parent of the current display root, then we are moving 
out of the displayed region. Therefore, the display root is moved to the parent of the new focus. The 
result is that the display gradually ‘‘zooms out” as the focus is shifted up the tree. This zooming may be 
too gradual when one is moving rapidly up the tree. A more complicated rule would locate the new root 
several above the new focus, so that it wouldn’t have to shift so often. 

*SetCurrentNode (return, E)^ *CurrentNode (X), Component (X, — , £*), 

*DisplayRoot (X), ^CurrentDepth (— ), Component (E^ — , D) 

=> DisplayRoot (D), CurrentNode (E), CurrentDepth (1), return (Nil). 

4- Upward Motion: No Shift Needed 

When we haven’t reached the root, we simply set the new focus. 

else *SetCurrentNode (return, fJ), *CurrentNode (X), Component (X, E), ^CurrentDepth (/) 

CurrentNode (E), CurrentDepth (/— l), return (Nil). 

5. Downward Motion: Shift Needed 

When the focus has reached the depth limit, it is moving out of the bottom of the displayed region of the 
tree. Therefore it is necessary for the display to “zoom in” to keep the displayed region visible. This is 
accomplished by shifting the display root to the parent of the new focus. This rapid zooming works well 
when the user is moving down into the tree rapidly. 

*SetCurrentNode (return, X), *CurrentNode (E), Component (X, E), *DisplayRoot (—), 

"‘'CurrentDepth (/), DepthLimit (rf), if (/^rf) 

CurrentNode (X), DisplayRoot (i^), CurrentDepth (l), return (Nil). 
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6. Downward Motion: No Shift Needed 



Wheit the depth limit has not been reached, the focus is simply shifted to the new node. 

*SetCurrentNode (return, X), *CurrentNode (J?), Component (X, — , E), 

DepthLimit (d), CurrentDepth (/), if (/<d) 

=?> CurrentNode (X), CurrentDepth (/+!), return (Nil). 

7. Arbitrary Motion 

All of the preceding cases assume that the focus is being shifted to a point neighboring the old focus. How- 
ever, search commands may move the focus large distances. In these cases we set the display root two 
nodes above the new focus, provided the tree extends up that far, otherwise it is set as high as possible. 

*SetCurrentNode (return, E), *CurrentNode (— ), *CurrentDepth (— ), *DisplayRoot (— ) 

=> {CurrentNode (J?); 

Component (J?, — , F), Component (F, — , G) ! set root two above 
=5> CurrentDepth (2), Display Root (G) 
else Component (J?, — , F) ! set root one above 
CurrentDepth (1), Display Root (F) 
else CurrentDepth (0), Display Root (J?); ! set root here 
return (Nil) } 

C. Editing 

i. Node Deletion 

We must “untag” the node (making it undefined), and sever all connections between it and its descen- 
dents. 

^Command (return, delete), CurrentNode [E]^ *Type [V, E) 

=> Purge (return, E), 

The Purge relation removes all the relevant Component tuples: 
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*Purge (return, £*), Component (X, — , E) 

=> — ’Component (Jf, — , E)^ Purge (return, E) 

else *Purge (return, E) 

Command (return, display). 

D. Program Entry 

When a key is struck we must ensure it is not an executive command (delete, in, out, etc.). To do this 
we will use a relation ExecutiveCommand, which contains all the executive command characters. When a 
program entry key is struck, we begin searching for its meaning with the nonterminal expected at that 
point. 

1, Initiate Search 

We ensure that the key is not an executive command and that the current node is undefined. Then we 
determine from the template associated with the type of its parent the syntactic category expected at this 
point. The search begins with the selector keys associated with this category. 

*Command (return, fc), — 'ExecutiveCommand (A:), CurrentNode (£*), 

-•Type (—, E)j Component (E, R, P), Type (V, P), 

AssumedTemplate ( T, V), Selector (P, /, T), Category (M, /, T) 

{OriginalNode (P); 

ProcessKey {A:, P, M}; 

-•OriginalNode (E); 
return (Nil) }. 

The relation OriginalNode saves the original node for restoration if the entered key is illegal. This is neces- 
sary since the forwarding process (optimistically) creates and focuses on subnodes as it forwards the key 
from nonterminal to nonterminal. See the rule for illegal key processing (below) for the use of Original- 
Node. 
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2, Key Starch 



If the given key is one of the selectors for this nonterminal, then the appropriate node type is instantiated. 

*ProcessKey (return, E, M), VariantKey (A:, V', M), Template ( T, V, M) 

{Type ( K, E); Instantiate (return, T, E)} 

If it is not, then it is forwarded to another nonterminal, if one is specified, otherwise an error occurs. There 
are two cases depending on whether or not the template is complex: 

else *ProcessKey (return, E", A/), DefaultNT (TV, M), — 'Complex (T) 

=> ProcessKey (return, k, E, TV) 

else *ProcessKey (return, k, E, A/), DefaultVar ( V^, Af), Default Tern plate (T, Af), 

Complex (T), FirstSelector (iJ, T), Selector (iJ, /, T), Category (TV, /, T) 

^ (Type (T, F); 

Instantiate { T, E}; 

Component (X, E, E) =?> ProcessKey (return, A:, X, TV) 

Note that the preceding rule automatically instantiates nodes. It is this action that necessitates the use of 
OriginalNode in the following rule; whatever nodes have been added are deleted: 

else *ProcessKey (return, k, E, Af), OriginalNode (X), Type (— , X) 

=> (SetCurrentNode {X}; 

Command {delete}; 

Error (return, “Illegal Key: " A:) }. 

The presence of instantiated nodes are detected by a defined Type. The following rule handles the case 
where no nodes were instantiated. 

else * ProcessKey (return. A:, E, Af) ! nodes have not been instantiated 
=?► Error (return, “Illegal Key: ” " A:). 

3. Node Instantiation: First Selector 

The first component of the new node is distinguished from the rest because the focus is automatically 
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shifted to this component. This facilitates left-to-right program entry. The following rule allocates a new 
node^ makes it the first component, and makes it the new focus: 

^Instantiate (return, T, £'), FirstSelector (i2, T), *Avail (X) 

Component (X, R, E)^ SetCurrentNode {A}, InstantiateRest (return, R, T, E), 

4- Node Instantiation: Other Selectors 

The remaining component nodes are created by an iterative process. When this has completed, the altered 
tree is unparsed, so that the user can see the template for the new node. 

*InstantiateRest (return, T, E), NextSelector (5, T), *Avail (A) 

=?► Component (A, 5, E), InstantiateRest (return, 5, T, E), 

*InstantiateRest (return, i2, T, E), -^NextSelector (—, R, T) 

=> Command (return, display). 

E. String Entry 

The command processor recognizes the spacebar command and accumulates into the Argument relation 
all characters typed up to the next return character. This command is allowed only if <chars> is the non- 
terminal associated with the current node. 

For example, consider the grammar rule; 

f <chars> 

=> Con (LitVal=<chars>) 

The generated tuples are: 

Type (Con, E], 

Component ( 7, LitVal, E) 

Type (Chars, V), 

Component (“ciC 2 * * * \ ‘‘charval”, V) 

The extra level of indirection is necessary to allow editing the string value. 
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i. Program Entry: Spacebar Command 



If the current node is undefined, but a string is expected, then the accumulated argument is made the 
string associated with the node, which is now of type Chars. 

^Command (return, spacebar), *Argument (s), CurrentNode (E), 

-iType (— , E), Component (E, R, P), Type ( K, P), 

AssumedTemplate (T, V)^ Selector (i?, /, T), Category (String, /, T) 

=> Type (Chars, E), Component («, “charval”, E), Command (return, display). 

The rule arrangement in Appendix A is slightly different, but not significantly so. 

2. Alternate String Entry 

The need to type the spacebar could be eliminated by making all commands (both executive and selector) 
nonprintable characters (e.g., control codes). Then, any printable character would automatically start 
string accumulation. Alternately, positioning the cursor on an undefined node of type <chars> could 
automatically trigger string accumulation. 

F. Unparsing 

The following sections describe the rules for unparsing the visible region of the program tree. Unparsing is 
initiated by the display command, which may be issued by the user or by the system (e.g., during edit- 

ing). 

1. display Command 
Begin at the display root: 

^Command (return, display), DisplayRoot (P), Type (— , E) 

=> Unparse (P), Waitimage (return, E). 

The Unparse relation requests the unparsing to start at E, The unparsed form is returned in Finallmage: 

*WaitImage (return, P), *FinalImage («, E) 

=> return (Display {«}). 
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Begin Unparsing 



Select a template based on the type of node: 

*Unparse (£J), Type (V, E), AssumedTemplate ( T, V') 

Scan (£', T, 0). 

This requests E to be unparsed (scanned) according to template T. The ‘0’ indicates that the current 
display depth is zero. 

3, Begin Image Accumulation 

To scan according to a template, we begin processing the first item in the template, starting with an empty 
image: 

*Scan (E, T, /) 

Processitem (£', T, /). 

4^ Terminals 

A terminal string is added to the image accumulated so far: 

*ProcessItem (£', 7, s, /), Terminal (7), Termin allmage (t, 7) 

=> MoveRight (E, 7, s '‘t, /). 

5. Move Right 

The MoveRight relation finds the next item in the template, or, if there is none, completes processing of 
the image. 

*MoveRight (E^ 7, s, /), Nextitem (J, 7, AT), 

Processitem (E, J, s, /) 

else * MoveRight (£', 7, /) 

=5> Image (s, E). 
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6. Nonterminal: Component Node 



Find the associated selector and through it initiate unparsing of the selected component. 

*ProcessItem [E^ /, /), — ’Terminal (/), Selector (/2, 7, T), 

Component [X, R, E), Category (N, 7, T), Complex (T) 

=> Pending (£, 7, «, X, /), FindTemplate (A", N, /+l). 

The Pending relation waits until the component is unparsed. FindTemplate requests unparse of the com- 
ponent at display level /+!. 

7. Nonterminal: Entire Node 

This occurs in simplex (as opposed to complex) templates. It is triggered by the absence of a selector for 
the nonterminal item. 

*ProcessItem (E^ 7, s, /), —’Terminal (7), Category (iV, 7, T), — -Complex (T) 

=> Pending (E, 7, «, E, /), FindTemplate (E, N, /). 

8. Nonterminal: Complete Processing 

When a final image has been computed for a pending nonterminal, we move right to the next item in the 
template: 

*Pending {E^ 7, s, A, /), *FinalImage (i, A) 

=> MoveRight (E, 7, « "t, /). 

9. Find Template: Undefined Node 

If the node is undefined, its image is the name of the nonterminal expected: 

^FindTemplate (£, A, /), -^Type (— , £), Nonterminallmage («, N) 

^ Image (“<” ^ ^ E). 

The Image relation is an intermediary before Finallmage, which is discussed later. 
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10, Find Template: Suppress Detail 



If the subtree is below the depth limit, then replace it by an ellipsis: 

*FindTemplate {E, N, /), Type (— , E), DepthLimit (d), if l>d 
^ Image E), 

Note that this rule is not used on undefined nodes. 

11. Find Template: Selected Template 

Select a template based on the type of the node: 

*FindTemplate (E, TV, /), Type (V, £’), Template ( T, V, TV), DepthLimit (d), if /^d 

==$» Scan (Ey T, /). 

12. Find Template: Default Template 

If there is no template corresponding to the node type, then use the default template: 

■*FindTemplate [E, TV, /), Type ( 7, E), -Template (-, V, TV), 

DefaultTemplate (T, TV), DepthLimit (d), if /^d 

Scan (£*, T, /). 

13. Find Template: Leaves 

We must handle specially the “leaves,” that is, the nodes corresponding to the <chars> nonterminal 
*FindTemplate (£, String, /), Type (Chars, £), Component («, “charval”, E) 

^ Image («, E), 

14- Final Image from Image 

The final image is computed from the image by toggling inverse video when we pass the focus node: 
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*Image («, £), CurrentNode (£), if (« Nil A first « invertjon) 

Fin allmage (invert __on " < ^ invertjoff, E) 

else *Image 

=5* Finallmage (a, E). 

V. Conclusions 

The investigation reported in “Experience with fl: Implementation of a Prototype Programming Environ- 
ment/’ Parts I through VI, has given us considerable experience in the use of f2 for a nontrivial applica- 
tion. We have gained some insight into the difficulties of programming a complex, highly-concurrent sys- 
tem in an object-oriented language. This has convinced us that object-oriented languages need some 
powerful linguistic mechanisms to help programmers think about time and control the relationship of 
events in time. 

We now believe that some form of modal or temporal logic, built into the language, is the best approach 
to this problem. In particular, in future research we intend to design linguistic structures that define tem- 
poral domains in much the same way that the control structures and scope structures of conventional 
languages define control-flow and naming domains. The goal of the linguistic structures is to avoid the 
complicated reasoning common to the use of first-order temporal logics. 
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APPENDIX A: Universal Syntax-Directed Editor 



The following is a loadable input file (‘PI6.USDE’) for the prototype universal syntax-directed editor 
described in this report. It is accepted by the McArthur interpreter [McArthur84], which differs in a few 
details from the Q notation used in this report (see [MacLennan84j). 

j 

! USDE — Universal Syntax Directed Editor 

j 

! RELATION DECLARATIONS 

! User Interface 

newrelation {^Command”}; 
newrelation {^Argument"}: 
newrelation {**Error**}; 

! Kinds of Templates 

newrelation {^‘Template**}: 
newrelation { *' DefauItT empla te** } : 
newrelation {‘^Complex"}: 

! Parts of Templates 

newrelation {"Nextltem"}; 
newrelation {"Terminal”}: 
newrelation ("Terminallmage"}: 

! Nonterminals 

newrelation ("Selector"}; 
newrelation ("Category"}; 
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newrelation {”IMonterminallmage'*}: 



! Display Control 

newrelation {"Root"}: 
newrelation ("DisplayRoot"}: 
newrelation ("CurrentNode"}: 
newrelation ("OriginalNode"}; 
newrelation ("DepthLimit"}: 
newrelation ("CurrentDepth"}; 
newrelation ("AssumedTemplate"}; 

! Variant Selection 

newrelation ("ExecutiveCommand"} 
newrelation ("VariantKey"}; 
newrelation ("DefaultlMT"}; 
newrelation ("DefauItVar"}; 

! Node Format 

newrelation ("FirstSelector" } : 
newrelation ("NextSelector"}; 
newrelation ("LastSelector"}; 

! Node Structure 

newrelation ("Type"}: 
newrelation ("Component"}: 

! Activities 

newrelation ("SetCurrentNode"}: 
newrelation ("Purge"}: 



newrelation {’Instantiate**}: 
newreiation {**lmage**}: 
newrelation {’’Finallmage**}: 
newrelation {**FindTemplate**}; 
newreiation {"Pending**}: 
newrelation {**MoveRight**}: 
newreiation {**Processitem**}: 
newrelation {**Scan**}: 
newrelation {"Unparse**}: 
newrelation {**Waitimage’*}: 
newrelation {**instantiateRest**}: 
newrelation {**ProcessKey**}: 
newreiation {**CreateFirst**}: 
newrelation {**CreateRest**}: 
newrelation {**CreateRoot**}. 

! Format Control Strings 

define {root, "ML". ** 

define {root, "invert^on". "{**}: 
define {root, "invert off**, **}**}. 

I chars — a special buiitin nonterminal 

define {root, "chars**, newobj {}}. 
AssumedTemplate (newobj {}, **chars**): 
Nonterminalimage ("chars", chars). 

! Table of Executive Commands 



ExecutiveCommand (**in**): 



ExecutiveCommand (”out**): 
ExecutiveCommand (”next"j: 
ExecutiveCommand (”prev”j; 
ExecutiveCommand ("root”): 
ExecutiveCommand ("display"): 
ExecutiveCommand ("delete"): 
ExecutiveCommand ("begin"). 



? THE RULES 



define {root. ''UnivSDErules", << 

! Error Handler 

if *Error (return, message) 

— > return (displayn {message}): 

! Focus Movement: 

! in Command 

if ‘Command (return, "in"). CurrentNode (E). Type (V. E). AssumedTemplate (T. V). 
FirstSelector (R. T). Component (X. R. E) 

-> {SetCurrentNode {X}; Command (return, "display")} 

else if ‘Command (return, "in") 

“> Error (return. "No inner component"); 

! out Command 

if ‘Command (return, "out"). CurrentNode (X), Component (X. — . E) 

— > (SetCurrentNode {E}; Command (return, "display")} 

else if ‘Command (return, "out") 

-> Error (return. "No outer component"): 

! next Command (next on same level) 

if ‘Command (return, "next"). CurrentNode (X). Component (X. R. E). Type (V. E). 
AssumedTemplate (T. V). NextSelector (S. R. T). Component (Y. S. E) 

— > {SetCurrentNode {Y}: Command (return, "display")}: 

! next Command (next on level above) 
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rf. ^Command (return. **next"), CurrentNode (X). Component (X, R. E). Type (V. E). 
AssumedTemplate (T. V). "Next Selector , R. T) 

-> {SctCurrentNode {E}; Command (return, "next")}: 

! next Command (no next node) 

if ^Command (return, "next"), CurrentNode (X). "Component (X. R, E) 

-> Error {"No next component"}: 

! prev Command (prev on same level) 

if ‘Command (return, "prev"). CurrentNode (X). Component (X. R. E). Type (V. E). 
AssumedTemplate (T. V). NextSelector (R. S. T). Component (Y. S. E) 

— > {SetCurrentNode {Y}: Command (return, "display")}: 

! prev Command (prev on level above) 

if ‘Command (return, "prev"). CurrentNode (X). Component (X. R. E). Type (V. E). 
AssumedTemplate (T. V). "NextSelector (R. S. T) 

-> {SetCurrentNode {E}: Command (return, "prev")}: 

! prev Command (no prev node) 

if ‘Command (return, "prev"). CurrentNode (X). "Component (X. R. E) 

— > Error {"No prev component"}: 

! root Command 

if ‘Command (return, "root"). Root (E) 

— > {SetCurrentNode {E}: Command (return, "display")}: 

! Upward Motion; Shift Needed 

if ‘SetCurrentNode (return. E). ‘CurrentNode (X). Component (X. E). ‘DisplayRoot (X). 

‘CurrentDepth (—). Component (E. — . D) 
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— > DisplayRoot (D). CurrentNode (E)» CurrentDepth (1). return (Nil) 



! Upward Motion: No Shift Needed 

else if *SetCurrentNode (return. E). ^CurrentNode (X). Component (X. — . E), ^CurrentDepth (I) 

— > CurrentNode (E). CurrentDepth (1—1), return (Nil) 

! Downward Motion: Shift Needed 

else if *SetCurrentNode (return. X), ^CurrentNode (E), Component (X. — . E). 

*DisplayRoot (— ). ‘CurrentDepth (I). DepthLimit (d). I >= d 

— > CurrentNode (X). DisplayRoot (E). CurrentDepth (1). return (Nil) 

! Downward Motion: No Shift Needed 

else if ‘SetCurrentNode (return. X). ‘CurrentNode (E). Component (X. — . E). 

DepthLimit (d). ‘CurrentDepth (I). I < d 
— > CurrentNode (X). CurrentDepth (l4-l). return (Nil) 

! Arbitrary Motion: Default Case 

else if ‘SetCurrentNode (return. E). ‘CurrentNode (— ). ‘CurrentDepth (— ). ‘DisplayRoot (— ) 

— > {CurrentNode (E): 

if Component'(E. — . F). Component (F. — . G) ! set root two above 
-> CurrentDepth (2), DisplayRoot (G) 
else if Component (E. — . F) ! set root one above 
— > CurrentDepth (1), DisplayRoot (F) 
else CurrentDepth (0). DisplayRoot (E): ! set root here 
return (Nil) 

}: 

! Editing Node Deletion 

if ‘Command (return, "delete”), CurrentNode (E). ‘Type (V. E) 
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— > Purge (return. E): 



if *Purge (return. E). Component (X. E) 

— > "Component (X. — . E). Purge (return. E) 

else if *Purge (return. E) 

— > Command (return, ^display”); 

! Program Entry: Initiate Search 

if ^Command (return, k). "ExecutiveCommand (k). CurrentNode (E). 'Type (— . E). 

Component (E. R. P). Type (V. P). AssumedTemplate (T. V). Selector (R, I. T). 

Category (M, I. T) 

1 

— > {OriginalNode (E): 

ProcessKey {k. E. M}: 

"OriginalNode (E): 
return (Nil)}; 

! Program Entry: Key Search 

if *ProcessKey (return, k. E, M). VariantKey (k. V. M). Template (T. V. M) 

. -> {Type (V, E): Instantiate (return. T. E) } 

else if *ProcessKey (return, k. E, M). DefaullNT (N. M). OefauItTemplate (T. M). "Complex (T) 
— > ProcessKey (return, k. E. N) 

else if ^ProcessKey (return, k. E. M). DefauItVar (V. M). OefauItTemplate (T. M). 

Complex (T). FirstSelector (R. T). Selector (R. I. T). Category (N. I. T) 

-> {Type (V. E): 

Instantiate {T. E}: 

if Component (X. R. E) —> ProcessKey (return, k. X. N) 

} 
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! Process Character Entry 



else if *ProcessKey (return, ” ”, E, chars). ^Argument (s) 

— > Type ("chars”. E). Component (s. "charval", E), Command (return, "display") 

else if *ProcessKey (return. ” ". E. M). ‘Argument (—) 

— > Error (return. "Characters not expected") 

! Process Illegal Key 

else if ‘ProcessKey (return, k. E. M), OriginalNode (X). Type (— . X) 

— > {SetCurrentNode {X}; 

Command {"delete"}: 

Error (return. "Illegal Key: " + k) 

} 

else If ‘ProcessKey (return, k. E. M) ! nodes have not been instantiated 
— > Error (return. "Illegal Key: -- + k): 

! Node Instantiation First Selector 

if ‘Instantiate (return. T. E). FirstSelector (R. T) 

-> CreateFirst (return. T. E. R, newobj {}): 

if ‘CreateFirst (return. T, E, R. X) 

— > Component (X. R. E), SetCurrentNode (X). InstantiateRest (return. R. T. E): 

I Node Instantiation: Other Selectors 

if ‘InstantiateRest (return, R. T. E). NextSelector (S. R, T) 

— > CreateRest (return. R. T. E. S, newobj {}): 

if ‘CreateRest (return, R. T. E. S. X) 

-> Component (X. S. E). InstantiateRest (return. S. T. E): 
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if ^InstantiateRest (return. R. T, E). "NextSelector (— , R. T) 

-> Command (return, "display"): 

! Alternate String Entry 
! Unparsing: display Command 

if ‘Command (return, "display"). DisplayRoot (E). Type (— . E) 

-> Unparse (E). Waitimage (return. E) 

else if Command (return, "display"). DisplayRoot (X). Component (X, — . E). ‘CurrentDepth (— ) 
-> DisplayRoot (E). CurrentDepth (1): 

if ‘Waitimage (return. E). ‘Finallmage (s, E) 

— > return (displayn {s}); 

! Begin Unparsing 

! Select a template based on the type of node: 

if ‘Unparse (E). Type (V. E). AssumedTemplate (T, V) 

-> Scan (E. T. 0): 

! Begin Image Accumulation 

if ‘Scan (E. T. I) 

-> Processitem (E. T. "". I): 

! Terminals 

if ‘Processitem (E. I. s. I). Terminal (I). Terminallmage (t, I) 

-> MoveRight (E. I. s + t. I): 

! Move Right 

if ‘MoveRight (E, I. s. I). Nextitem (J, I, N) 
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— > Processitem (E. J, s, I) 



dsc if *MoveRight (E. I, s. I) 

— > Image (s, E); 

! Nonterminal: Component Node 

if ^Processitem (E. I. s. I), "'Terminal (I). Selector (R. I. T). 

Component (X, R, E), Category (N, I, T). Complex (T) 

-> Pending (E, I. s. X. I). FindTemplate (X. N. 1+1); 

! Nonterminal Entire Node 

if ^Processitem (E. I. s. I). ^Terminal (I). Category (N. I. T). "^Complex (T) 

— > Pending {E. I. s. E. I), FindTemplate (E. N, I): 

! Nonterminal: Complete Processing 

if ^Pending (E. \, s. X. I). *Finallmage (t. X) 

— > MoveRight (E. I. s + t. I); 

! Find Template: Undefined Node 

if ^FindTemplate (E, N, I), "Type {—. E). Nonterminallmage (s, N) 

-> Image (”<” + s + E): 

I Find Template: Suppress Detail 

if ^FindTemplate (E. N. I). Type (— . E), DepthLimit (d), l>d 
-> Image E); 

! Find Template: Selected Template 

if ♦FindTemplate (E. N. I). Type (V. E). Template (T. V. N). DepthLimit (d). I <= d 
-> Scan (E. T. I); 
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f Find Template: Default Template 



if *FindTemplate (E, N. I). Type (V. E). "Template (— V. N), 

OefauItTemplate (T. N). DepthLimit (d). I <= d 
-> Scan (E. T. I); 

! Find Template: Leaves 

if ^FindTemplate (E. chars. I), Type ("chars". E). Component (s. "charval". E) 

-> Image (s. E): 

! Final Image from Image 

if *lmage (s. E). CurrentNode (E), s != Nil. first [s] != invert_on 

— > Finallmage (invert on + s + invert_off. E) 

else if ^Image (s. E) 

-> Finallmage (s. E): 

! begin Command 

if ^Command (return, "begin") 

— > CreateRoot (return, newobj {}. newobj {}): 

if *CreateRoot (return. E. P) 

-> {Type ("prog". P). Root (P). Component (E. P). DisplayRoot (P). CurrentNode (E): 

Command (return, "display")}: 

»}. 

act {UnivSDErules}. 

) Initialize Parameters 
DepthLimit (5): 
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CurrentDepth (1). 



displayn {''Universal SDE loaded."}. 



APPENDIX B: Table Builder for Universal SDE 



The following is a loadable input file (‘PiG.utir) defining the table building and other utiCty rules for the 
universal syntax- directed editor. It assumes the definitions of Appendix A. 

I 

! Utility Relations and Rules for USDE 

I 

newrelation {"newobject”}; 
newrelatton {"defnt”}: 
newrelation {"defnt2”}: 

newrelation {"CrTempI”}: 
newrelation {"CrTempIO”}: 
newrelation {"CrTempIl”}; 
newrelation {”CrTempl2”}: 
newrelation {**CrTempl3”}: 
newrelation {"CrTempl4”}; 

newrelation {'*CrVar”}: 
newrelation {”CrDef”}: 
newrelation {’’CrSimDef”}: 
newrelation {"DefSel"}: 

newrelation {"PrNT*'}: 
newrelation {"PrVariant"}: 
newrelation {"PrSirnDef”}: 
newrelation {"PrDef"}: 

newrelation {’'PrTempI"}; ^ 

newrelation {"PrTempIl**}; 
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newrelation {"Script"}: 
newrelation {"PendScript"). 

define {root. "PIGutil", << 

! newobject {n} — defines a new object named n’ 
if *newobject (return. IM) 

-> {define {root, N. newob] {}}: return (Nil)}: 

! defnt {nt} - define nonterminal named nt' 

if *defnt (return. S) 

— > defnt2 (return. S. newob]{}): 

if *defnt2 (return, S, N) 

-> {define {root. S. N}: Nonterminallmage (S, N)}: 

! CrTempI {NT. tempi— descr} — construct template; return 1st item 
if ‘CrTempI (return. N. Nil) 

-> {display {"Error: empty template for "}: displayn {N}} 

else if ‘CrTempI (return, N. Z) 

— > CrTempIO (return. N. Z. newob] {}): 

if ‘CrTempIO (return. N. Z. T) 

-> CrTempIl (return. N. Z, T. T): 

if ‘CrTempIl (return. N. Z. T. I) 

— > {if IsList [first [ZJ] 

-> CrTempl2 (return. N. first [rest [first [Z]]], first [first [Zj], 
rest [Z). T. I) 

else CrTempl3 (return. N, first [Z]. rest [Zj, T, I) }: 
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if *OTempl2 (return. N. M. R. Z. T. I) 

— > {Selector (R, I, T), Category (M. I. T): 

DefSel (R. T}: 

CrTempW (return. N. Z. T. I. N) 

}: 

if *CrTempl3 (return. N. S. Z. T. I) 

— > Terminal (I). Terminallmage (S. I), CrTempl4 (return. N. Z. T. I. N); 

if *CrTempl4 (return. N. Nil. T. I. N) 

— > return (I) 

else if *CrTempl4 (return. N. Z. T. I. N) 

— > Nextitem (CrTempIl (N. Z. T. newobj {}}. I. N), return (I): 

! CrVar (NT. key, type, template} 

! Create variant 

if *CrVar (return. N. K. V. Z) 

— > (VariantKey (K. V. N). Template (CrTempI (N. Z), V. N); 

If Template (T. V. N) — > AssumedTemplate (T. V). Complex (T): 
return (Nil) 

}: 

! CrDef (NT. default variant, template} 

! Create default 

if *CrDef (return. M. V. Z) 

-> {DefauItVar (V. M). DefauItTemplate (CrTempI {M. Z}, M); 

if DefauItTemplate (T. M) -> AssumedTemplate (T. V). Complex (T); 
return (Nil) 

}: 
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? CrSimDef {NT, left. NT*, right} - Create simplex default 



»f ^CrSimDef (return, M, s. N. t) 

— > (DefaultNT (N. M). DefauItTemplate (CrTempI (M, [s. N], tj). M): 

return (Nil) 

}: 

! DefSel {R. template} — Define next selector for template 

if *DefSel (return. R. T), "'Last Selector (— . T) 

— > FirstSelector (R. T). LastSelector (R. T), return (Nil): 

if *DefSel (return. S. T). *LastSelector (R. T) 

— > NextSelector (S. R. T), LastSelector (S. T). return (Nil): 

! PrNT {NT} — print nonterminal's name 

if *PrNT (return. N). Nonterminallmage (S. N) 

-> {displayn {""}: displayn {S + ":"}}: 

! PrVariant {NT. key} — print selected variant 

if *PrVariant (return. N. K), VariantKey (K. V. N). Template(T, V. N). Complex (T) 
-> {display {"*^» 4. K + "*(" + V + ") -> "}: 
return (PrTempI {T}) 

}: 

! PrSimDef {NT} — print simplex default variant 

if *PrSimDef (return. M). DefaultNT (N. M). DefauItTemplate (T. M) 

“> {display {"else <"}: display {N}: display {"> -> "}: 
return (PrTempI {T}) 

}: 
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t PrDef {NT} — print complex default variant 



if •PrDef (return. M). DefauItVar (V, M), DefauItTemplate (T, M) 
-> (display ("else (" -h V -f *') -> "}: 
return (PrTempI {T}) 

}: 

! PrTempI (item) — print template 

if *PrTempl (return. I). Terminal (I). Terminallmage (S. I) 

— > (display (" " + S + return (PrTempIl (I})}; 

if *PrTempl (return. I). Selector (R. I. T), Category (M. I. T) 

-> (display (" " + R + display(M}: display (’^>"}; 

return (PrTempIl (!}) 

}: 

if *PrTempll (return. I), "Nextitem (J. I. N) 

-> display n ("."} 

else if ^PrTempIl (return. I). Nextitem (J. I. N) 

— > PrTempI (return. J): 

! Script (s) — Execute Command Script s 

if ‘Script (return. Nil) 

— > return ("Done") 

else if ‘Script (return, s). first [sj = " " 

— > (displayn (" 

displayn (" + first [rest [s]]}: 

Argument (first [rest [s]]); 

Command (first [s]}; 
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if "Command (-*. — ) -> Script (return, rest [rest [s]]) 
else PendScript (return, rest [rest [s]]) 

} 

else if ‘Script (return, s) 

-> {displayn 

displayn {” " + first [s]}: 

Command {first [s]}: 

if "Command (— , — ) — > Script (return, rest [sj) 
else PendScript (return, rest [sj) 

}: 

if ‘PendScript (return, s). "Command (— . — ). "Waitimage (— . — ) 
-> Script (return, s): 

»}. 

act {PISutil}. 

displayn {"PI-6 Utilities activated."}. 
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APPENDIX C: Sample Transaction Grammar 



The following is a loadable input file (‘PIG.testgram’) that constructs the grammar tables for the sample 
language used in the body of the report. 

I 

1 Transaction Grammar for Simple Applicative Language 
1 

! Define Nonterminals 

defnt {"program”}: 
defnt {"expr"}: 
defnt ("arex"}; 
defnt ("term"}; 
defnt {"factor"}: 
defnt {"var"}. 

! <program> = (prog) *:<expr>. 

CrDef {program, "prog". [["*", expr]]}. 

PrNT {program}: 

PrDef {program}. 

! <expr>: 

! =(eql) — > left:<arex> = right:<arex> 

! n (neq) — > left:<arex> <> right:<arex> 

! else <arex> 

CrVar {expr. "eql". [["left", arex], " = ", ["right", arex]]}: 

CrVar {expr. "n". "neq". [["left", arex]. " <> ", ("right", arex]]}; 

CrSimDef {expr. "", arex. ""}. 
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PtNT {expr}: 

PrVariant {expr. 

PrVariant (expr. "n"}: 

PrSimDef {expr}. 

! <arex>: 

! + (sum) -> left:<arex> -h right:<term> 

! — (dif) -> left:<arex> - right;<term> 

! else <term> 

CrVar {arex. "sum”, [["left", arex]. " -h ["right", term]]}: 
CrVar {arex, "dif". [["left", arex], " - ", ["right", term]]}: 
CrSimDef {arex. term. ""}. 

PrIMT {arex}: 

PrVariant {arex. "+"}: 

PrVariant {arex. 

PrSimDef {arex}. 

! <term>: 

! * (prd) -> left:<term> x right:<factor> 

! / (quo) -> left:<term> / right:<factor> 

! else <factor> 

CrVar {term. "prd". [["left", term). " x ". ["right", factor]]}: 
CrVar {term. "/", "quo", [["left", term], " / ", ["right", factor]]}: 
CrSimDef {term. "", factor. ""}. 

PrlSIT {term}: 

PrVariant {term, "*"}: 

PrVariant {term. "/"}: 

PrSimDef {term}. 
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<factor>: 



! # (con) — > litval:<chars> 

? c (call) — > rator:<chars> rand:<factor> 

\ ( (par) -> ( exp:<expr> ) 

! i (conex) — > 

[ (if cond:<expr> 

! then conseq:<expr> 

! else alt:<expr> ) 

! I (block) -> 

! [let bndvar:<chars> = bndval:<expr> 

! body:<expr> ] 

! f (fundef) — > 

! [func funname:<chars> funformal:<chars> = funbody:<expr> 

! funscope:<chars> ] 

! else (var) — > ident:<chars> 

CrVar {factor, "con", [["litval", chars]]}: 

CrVar (factor, "c". "call", [["rator", chars], " ", ("rand", factor]]}: 

CrVar (factor, "(", "par". ["(", ["exp", expr], ")"]}: 

CrVar (factor, "i", "conex", 

[NL -f "(if ", ("cond", expr], 

NL -{- " then ", ("conseq", expr], 

ML + " else ", ("alt", expr], " )"]}: 

CrVar (factor, "I", "block". 

[NL -f- "(let ", ["bndvar", chars], " = ". ("bndval". expr], 

NL. ("body", expr], " ]"]}: 

CrVar (factor, "f". "fundef". 

[NL -h "[func ", ["funname", chars], " ", ["funformal", chars], " = ", ["funbody", expr], 
NL, ["funscope", expr], " ]"]}; 
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CrDef {factor, "var", [("ident”, chars]]}. 



PrNT {factor}: 

PrVariant {factor, "#"}; 

PrVariant {factor, "c"}: 

PrVariant {factor. "("}: 

PrVariant {factor, "i"}: 

PrVariant (factor, "I"}: 

PrVariant {factor, "f"}; 

PrDef {factor}. 

displayn {"Test Grammar loaded."}. 

define {root, "test script". 

("begin", "f". " ", "fac", "next". " ". "n". "next". 

iijii ii_ii tt ti ti|jii ii|)ext" " " "0" 

"next".."#", " ", "1". "next". 

"♦" It II Mpii »next". "c". " ". "fac". "next". 

ii_M ii|ii ii_ii II II iiijii "pcxt" "#" " " "1" "next" 

"I". " ", "alpha", "next". "*". "#". " ". "512". "next". "#". " ". "3" 
"next", "c". " ". "fac". "next". " ". "alpha", "root"]}. 
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APPENDIX D: Transcript of Q Session 



The following is a transcript of an Cl session illustrating the operation of the prototype universal syntax 
directed editor and utilities presented in Appendices A and B, operating on the sample transaction gram- 
mar of Appendix C. The assertion ‘Script {testjscript}’ causes the commands in testscript to be executed 
in order. Each command is printed on a separate line, followed by whatever output is generated by the 
programming environment. This transcript was produced by the McArthur interpreter [McArthur 84 ]. 

% omega 

OMEGA-1 11/30/84 

Use CntI— D or exit{} to quit. 

For help, enter help{"?"}. 

To report a bug. enter Bugs{}. 

newrelation rule activated. 

doit/redo activated: use doit' instead of do’. 

> do {"PI6.USDE”}. 

Universal SDE loaded. 

OK 

> do {"Pie.util"}. 

PI— 6 Utilities activated. 

OK 

> do {”PI6.testgram”}. 
program: 

else (prog) — > *:<expr>. 
expr: 

*=* (eql) — > left:<arex> ‘ = ’ right:<arex>. 

*n’ (neq) -> left:<arex> * <> ' right:<arex>. 
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else <arex> — > ** *:<arex> 



arex: 

+ ' (sum) — > lefl:<arex> * + * right:<term>. 

— ' (dif) — > left:<arex> ‘ — ' right:<term>. 
else <term> — > “ *:<term> *. 

term: 

*■ (prd) — > left:<term> ‘ x ‘ right:<factor>. 

7' (quo) — > left:<term> ‘ / ‘ right: <factor>. 
else <factor> — > *' *:<factor> 

factor: 

(con) — > litval:<chars>. 
c‘ (call) — > rator:<chars> ' ' rand:<factor>. 

'(’ (par) — > (‘ exp:<expr> )'. 

i‘ (conex) — > 

(if ' cond:<€xpr> 
then ' conseq:<expr> 
else ‘ alt:<expr> * )*. 
r (block) -> 

[let ' bndvar:<chars> ‘ = ’ bndval;<expr> 

*r (fundef) -> 

[func ' funname:<chars> ‘ ' funformal:<chars> ‘ = ' funbody:<expr> 
else (var) — > ident:<chars>. 

Test Grammar loaded. 

OK 

> Script {test_script}. 



begin 
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{,<expr>} 



f 

[func {<chars>} <chars> = <expr> 
<expr> I 



— .fac 

[func {fac} <chars> = <expr> 
<expr> I 



next 

[func fac {<chars>} = <expr> 
<expr> ) 



[func fac {n} = <expr> 
<expr> ] 



next 

[func fac n = {<expr>} 
<expr> ] 



i 

[func fac n = 
(if {<expr>} 
then <expr> 
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dsc <expr> ) 
<expr> J 



[func fac n = 

(if {<arex>} = <arex> 
then <expr> 
else <expr> ) 

<expr> ] 



— n 

[func fac n = 

(if {<chars>} = <arex> 
then <expr> 
else <expr> ) 

<expr> ] 

[func fac n = 

(if (n} = <arex> 
then <expr> 
else <expr> ) 

<expr> I 



next 

(if n = {<arex>} 
then <expr> 
else <expr> ) 
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# 



(if n = {<chars>} 
then <expr> 
else <expr> ) 



_0 

(if n = {0} 
then <expr> 
else <expr> ) 



next 

[func fac n = 

(if n = 0 
then {<expr>} 
else <expr> ) 
<expr> ] 



# 

[func fac n = 

(if n = 0 
then {<chars>} 
else <expr> ) 
<expr> ] 



[func fac n = 



- 60 - 



(if n = 0 
then {1} 
else <expr> ) 
<expr> J 



next 

[func fac n = 

(if n = 0 
then 1 

else {<expr>} ) 
<expr> ] 



[func fac n = 

(if n = 0 
then 1 

else {<term>} x <factor> ) 
<expr> ] 



[func fac n = 

(if n = 0 
then 1 

else {<chars>} x <factor> ) 

<expr> ] 

[func fac n = 

(if n = 0 
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then 1 



else {n} x <factor> ) 
<expr> ] 



next 

(if n = 0 
then 1 

else n x {<factor>} ) 



c 

(if n = 0 
then 1 

else n x {<chars>} <factor> ) 



_fac 

(if n 0 
then 1 

else n x {fac} <factor> ) 



next 

n X fac {<factor>} 



n X fac {<chars>} 
n X fac {<factor>} 
Illegal Key: — 
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( 

n X fac ({<expr>}) 



n X fac ({<arex>} - <term>) 



— .n 

n X fac ({<chars>} — <term>) 
n X fac ({n} - <term>) 



next 

(n — {<term>}) 



# 

(n - {<chars>}) 



(n - {1}) 



next 

[func fac n = 

(if n = 0 
then 1 

else n x fac (...) ) 
(<expr>} ] 



I 

[func fac n = 
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(if n = 0 
then 1 

else n x fac (...) ) 

[let {<chars>} = <expr> 
<expr> ] ] 



_alpha 

[func fac n = 

(if n = 0 
then 1 

else n x fac (...) ) 

[let {alpha} = <expr> 
<expr> J I 



next 



[func fac n = 
(if n = 0 
then 1 



else n x fac (... - ...) ) 



[let alpha = {<expr>} 
<expr> ] ] 



* 



[func fac n = 
(if n = 0 
then 1 
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dse n X fac (... — ...) ) 



pet alpha = {<term>} x <factor> 
<expr> ] ] 



# 

[func fac n = 

(if n = 0 
then 1 

else n x fac (... — ...) ) 

[let alpha = {<chars>} x <factor> 
<expr> ] ] 



-512 

[func fac n = 

(if n = 0 
then 1 

else n x fac (... - ...) ) 

[let alpha = {512} x <factor> 
<expr> ] ] 



next 

[let alpha = 512 x {<factor>} 
<expr> ] 



# 
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[let alpha = 512 x {<chars>} 
<«xpr> J 



_3 

[let alpha = 512 x {3} 
<expr> I 



next 

[func fac n = 

(if n = 0 
then 1 

else n x fac (... - ..) ) 

[let alpha = 512 x 3 
{<expr>} 1 ] 



c 

[func fac n = 

(if n = 0 
then 1 

else n x fac (... — ...) ) 

[let alpha = 512 x 3 
{<chars>} <factor> ] ] 



_fac 

[func f ac n = 

(if n = 0 
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then 1 



else n x fac — ...) ) 

[let alpha = 512 x 3 
{fac} <factor> ] ] 



next 

[let alpha =: 512 x 3 
fac {<factor>} j 



_alpha 

[let alpha = 512 x 3 
fac {<chars>} ] 

[let alpha = 512 x 3 
fac {alpha} ] 



root 

{ 

[func fac n = 

(if n = 0 
then 1 

else n x fac (...) ) 

[let alpha = 512 x 3 
fac alpha ] ]} 

Done 

> "DepthLimit(5), DepthLimit(20). 
20 
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> Command {"display”}. 

{ 

[func fac n = 

(if n = 0 
then 1 

else n X fac (n — 1) ) 

[let alpha = 512 x 3 
fac alpha ] ]} 

OK 

> exit {}. 

Goodbye. 
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